Hi all,

I find this backport problematic. Given the points in [1]/[2]/[3] below, we might want to avoid backporting it.

Rationale
The idea of backporting this change is the following:

• The change is valuable because it eliminates fragile code paths and prevents potential out-of-bounds memory access
• There exist other changes that depend (transitively) on this one:
  • JDK 8321509: False positive in get_trampoline fast path causes crash
  • ->JDK-8298913: Add override qualifiers to Relocation classes
  • ->JDK-8160404: RelocationHolder constructors have bugs

[1]
The change requires JDK-8299022, which addresses PPC/S390 build issues. Can we include it as a commit in this PR or it should go as a separate change?

• commit_2: 8299022: Linux ppc64le and s390x build issues after JDK-8160404

[2]
While working on the backport, I encountered a build issue: the AArch64 cross-compiler reports that Address::_ext is used uninitialized in a copy constructor. This can be resolved with a simple fix (see commit_3). However, I find it concerning that:

• the same code (with identical gcc options) does not produce a build error on the OpenJDK mainline; and
• for backporting, the correct approach is to backport existing changes rather than patching gaps with new commits.

[3]
The original patch also modifies the post_call_nop_Relocation and entry_guard_Relocation classes, which are part of:

• 8284161: Implementation of Virtual Threads (Preview)
• 8290700: Optimize AArch64 nmethod entry barriers

I do not expect these changes to be backported to jdk17u, so I have excluded those parts in this backport:

@@ -935,29 +996,29 @@ class DataRelocation : public Relocation {
 };

 class post_call_nop_Relocation : public Relocation {
-  friend class RelocIterator;
+  friend class RelocationHolder;

 public:
   post_call_nop_Relocation() : Relocation(relocInfo::post_call_nop_type) { }

   static RelocationHolder spec() {
-    RelocationHolder rh = newHolder();
-    new(rh) post_call_nop_Relocation();
-    return rh;
+    return RelocationHolder::construct<post_call_nop_Relocation>();
   }
+
+  void copy_into(RelocationHolder& holder) const;
 };

 class entry_guard_Relocation : public Relocation {
-  friend class RelocIterator;
+  friend class RelocationHolder;

 public:
   entry_guard_Relocation() : Relocation(relocInfo::entry_guard_type) { }

   static RelocationHolder spec() {
-    RelocationHolder rh = newHolder();
-    new(rh) entry_guard_Relocation();
-    return rh;
+    return RelocationHolder::construct<entry_guard_Relocation>();
   }
+
+  void copy_into(RelocationHolder& holder) const;
 };

 // A CallRelocation always points at a call instruction.

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• JDK-8160404 needs maintainer approval

Issue

• JDK-8160404: RelocationHolder constructors have bugs (Bug - P4) ⚠️ Issue is already resolved. Consider making this a "backport pull request" by setting the PR title to Backport <hash> with the hash of the original commit. See Backports.

Reviewing